Skip to content

fix: reading a book no longer freezes a moving train - #597

Open
bh679 wants to merge 2 commits into
mainfrom
dev/book-screen-no-pause
Open

fix: reading a book no longer freezes a moving train#597
bh679 wants to merge 2 commits into
mainfrom
dev/book-screen-no-pause

Conversation

@bh679

@bh679 bh679 commented Jun 26, 2026

Copy link
Copy Markdown
Owner

Summary

Reading a written book in singleplayer on the moving Sable train made the carriage group under the player's feet (plus neighbours) vanish ~1 s later, returning only on a world reload.

Root cause: DT's books open the vanilla BookViewScreen, which inherits Screen.isPauseScreen() (defaults to true) without overriding it (confirmed via javap). Opening a book pauses singleplayer → triggers a full autosave → Sable's saveAll() shuffles the train's sub-levels through holding chunks, and the resume (book close) fails to restore the sub-levels around the player (Attempted to snatch sub-level … wasn't present in the holding chunk / Received a sub-level movement packet for a non-existent sub-level), vanishing the carriages.

This adds the isPauseScreen() → false override Mojang omitted, via a client mixin, so reading a book no longer pauses/autosaves a run mid-ride — the train keeps moving while you read.

Implemented as an additive method merge, not @Inject: since BookViewScreen doesn't declare isPauseScreen() (it's inherited from Screen), an @Inject targeting BookViewScreen would fail to resolve at apply-time and crash on load.

Scope / trade-off

  • Affects all written-book reads in singleplayer (starting, chest, story books). Intended.
  • No multiplayer effect — MP never pauses on a screen.
  • Behaviour change: the world keeps ticking while reading, so the player can take damage / be attacked mid-read (arguably more correct on a constantly-moving roguelite train).
  • Out of scope: ESC-menu / advancement-popup pauses can still cause the same Sable desync — the durable Sable-side fix is a separate task.

Mod impact

One new client mixin. No new deps, no MC/NeoForge/Sable bump, no new blocks/items/entities, no world-gen or networking changes.

Changes

  • src/main/java/games/brennan/dungeontrain/mixin/client/BookViewScreenNoPauseMixin.java (new)
  • src/main/resources/dungeontrain.mixins.json (register client.BookViewScreenNoPauseMixin)
  • gradle.properties mod_version 0.367.0 → 0.368.0
  • .github/release-notes/changelog.json (player-facing fix entry)

Test plan

  • ./gradlew build — pass; build/libs/dungeontrain-0.368.0.jar (8.3 MB)
  • Unit tests — 924/924 pass (98 suites, 0 failed)
  • ./gradlew runClient — launches clean; log confirms the mixin applies into BookViewScreen with no apply error
  • In-game (Sable train): open a book on the moving train → no Saving and pausing game… on open, no Sable snatch/holding-chunk errors on close, no carriages vanish, train keeps moving

🤖 Generated with Claude Code

bh679 and others added 2 commits June 26, 2026 20:23
…train

Vanilla BookViewScreen inherits Screen.isPauseScreen()=true and doesn't
override it, so reading a written book pauses singleplayer and triggers a
full autosave. On a moving Sable train that autosave shuffles sub-levels
through holding chunks and the resume fails to restore them, vanishing the
carriages around the player until a world reload.

Add an isPauseScreen()=false override to BookViewScreen via a client mixin
(an additive method merge, not @Inject — BookViewScreen doesn't declare the
method, so an @Inject would fail to resolve at apply-time). Reading a book
no longer pauses/autosaves a run mid-ride; the train keeps moving.

Scope: book screen only; ESC-menu / advancement-popup pauses are handled in
a separate session. Bumps mod_version 0.367.0 -> 0.368.0 (MINOR; main is at
PATCH=0 with the cascade paused, so version-bump.yml skips its merge bump)
and logs the player-facing changelog entry.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant